home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
BBS Toolkit
/
BBS Toolkit.iso
/
rbbs_pc
/
rbbsnet.zip
/
RBBS-NET.DOC
< prev
next >
Wrap
Text File
|
1992-07-14
|
36KB
|
1,063 lines
R B B S - N E T
Policy and Procedures Guide
Draft 1.9
July 13, 1992
Section Page
------- ----
1 Overview ...................................................... 3
1.1 Objectives ................................................ 3
1.2 Background ................................................ 3
1.3 Definitions ............................................... 3
1.4 The Levels of RBBS-NET .................................... 4
2 Sysop Procedures .............................................. 5
2.1 How to get a node number .................................. 5
2.2 If you are going down ..................................... 6
2.3 How to join a network ..................................... 6
2.4 How to form a network ..................................... 7
3 Network Coordinator Procedures ................................ 8
3.1 Routing inbound mail ...................................... 8
3.2 Assigning node numbers .................................... 8
3.3 Maintaining the Node List ................................. 8
3.4 Passing along Node Lists and RBBS-NET News ................ 9
4 Network Administration Procedures ............................. 10
4.1 Assigning node numbers .................................... 10
4.2 Encouraging the formation and growth of networks .......... 10
4.3 Assigning network numbers ................................. 11
4.4 Maintaining the Node List ................................. 11
4.5 Overseeing network operations ............................. 12
4.6 Passing along Node Lists and RBBS-NET News ................ 12
5 EchoMail Conferences .......................................... 13
6 RBBS-PC Network Contact People ................................ 16
7 Acknowledgments ............................................... 17
RBBS-PC Network Policy and Procedures Page 2
Chapter 1
OVERVIEW
1.1 Objective
To connect RBBS-PC System across the Nation into a FidoNet Compatible
Network for the "Free Exchange of Information."
We (The RBBS-PC Network) have no intentions of trying to replace or
compete with the existing FidoNet Network. We (The RBBS-PC Network)
only want a means of communicating directly with other RBBS-PC SysOps
across the nation and to enhance the transmission of messages across
the nation and to further develope RBBS-PC.
This document is an attempt to describe the procedures which have
been developed to manage The RBBS-PC Network (RBBS-NET).
1.2 Background
FidoNet is an amateur electronic mail system. From its early
beginnings as a few friends swapping messages back and forth, it has
now grown to (April 1992) over 12000 different systems on four
continents.
RBBS-NET is going to provide the resources to a RBBS-PC System
Operator (SysOp) with the tools to connect into a Network of other
Bulletin Board (BBS) SysOps across the nation. We hope to be able to
provide international connectivity also.
RBBS-NET will not try to reinvent the wheel. We will adopt most of
of the standards that International FidoNet Association has already
adopted into their network.
1.3 Definitions
RBBS-NET nodes are grouped on several levels. These are as follows:
Nodes: A node is a single Net address, and is the smallest
recognized unit of the Net.
Networks: A network is a collection of nodes, usually in a
relatively small geographic area. Networks coordinate
their mail activity to decrease cost and increase mail
throughput.
Hubs: Is another Network within an existing Network. Hubs
are treated just like Networks. Therefore, all that
applies for Networks ... also applies for Hubs.
Regions: (Not applicable)
A region is a well defined geographic area containing
nodes which may or may not be combined into networks.
A typical region will contain many nodes in networks,
and a few independent nodes, which are not a part of
any network.
RBBS-PC Network Policy and Procedures Page 3
Zones: (Not applicable)
A zone is a large geographic area containing many
regions, and covering one or more countries and/or
continents.
RBBS-NET: This indicates the entire mail network, as designed by
the RBBS-PC Network Coordinators and as defined by the
weekly Node List.
1.4 The Levels of RBBS-NET
With the introduction of The RBBS-PC Network, RBBS-NET has developed
the following levels of organization:
The Network Coordinator
The Network Coordinator compiles all of the Node Lists
from all of the Networks and creates the master Node List,
which is then distributed across The RBBS-PC Network.
The Network Manager
The Network Manager is responsible for maintaining the
list of nodes for his network, and for receiving and
forwarding any mail coming to the network from the outside.
He is also responsible for the maintenance of the members of
his network and will insure proper use of the network by those
members.
The Network Routing Hub
Network Routing Hubs exist only in three-tiered networks. They
generally share some or all of the duties of the Network
Coordinator, in order to ease the management of a large
network. The exact duties and procedures are a matter for the
Network Coordinator and his hubs to settle, and will not be
discussed here. The Network Coordinator is still responsible
for the maintenance of the network and insures proper use of
the network for the people in his Routing Hub.
The System Operator (SysOp)
The SysOp formulates his own policy for running his board and
dealing with his users, so that will not be discussed in this
document. However, the sysop must also mesh with the rest of
the RBBS-NET Systems if he is to send and receive mail, and
that will be discussed here.
The User
Policy and procedures for the individual user on any given
board is determined by the system operator of that board, and
will not be considered in this document.
These levels act to distribute the administration and control of
RBBS-NET to the lowest possible level, while still allowing for
coordinated action over the entire mail system.
RBBS-PC Network Policy and Procedures Page 4
Chapter 2
SYSOP PROCEDURES
A SysOp of an individual node can pretty much do as he pleases, as
long as he observes the mail events, is not excessively annoying to
other nodes on RBBS-NET or any other FidoNet Compatible Network
and does not promote the distribution of pirated copyrighted software.
National Mail Hour is the heart of any NetMail Network, as this is
when the network mail is passed between systems. Any system which
wishes to be a part of a NetMail Network must be able to receive mail
at this time. A system which is a member of a network may also be
required to observe additional mail events, as defined by his Network
Coordinator.
Network mail systems generally operate unattended, and place calls at
odd hours of the night. If a system tries to call an incorrect or out
of date number, it could cause some poor citizen's phone to ring in
the wee hours of the morning, much to the annoyance of innocent
bystanders and civil authorities. For this reason, a SysOp who sends
mail is obligated to obtain and use the most recent edition of the
Node List as is practical.
The exact timing of National Mail Hour is set for each zone by the
International Coordinator, or by his designated Zone Coordinator. In
the United States, National Mail Hour is observed from 0900 to 1000
GMT every day, weekends included. In each of the United States time
zones, this would be as follows:
Eastern Standard Time 4 AM to 5 AM
Central Standard Time 3 AM to 4 AM
Mountain Standard Time 2 AM to 3 AM
Pacific Standard Time 1 AM to 2 AM
Hawaii Standard Time 11 PM to Midnight
Networks do not observe daylight savings time. In areas which observe
daylight savings time the RBBS-NET mail schedules must be adjusted
in the same direction as the clock change. Alternatively, you can
simply leave your system on standard time.
2.1 How to get a node number
You must first obtain a current Node List so that you can send mail.
You do not need a node number to send mail, but you must have one in
order for others to send mail to you.
The first step in obtaining a current Node List is to locate the
closest RBBS-NET Bulletin Board System to you.
If the SysOp of any RBBS-NET system does not have a Node List available
for downloading, then he can probably tell you where to get one, BUT we
STRONGLY suggest all nodes carry and allow for download the most recent
RBBSLIST.Z?? and related RBBS-NET files.
RBBS-PC Network Policy and Procedures Page 5
Once you have a Node List, you must determine which network or region
covers your area. If you are unsure of this or there is not one in
your area, send the information to the Network Coordinator.
Once you have located the network or region in your area, send a
request for a node number to node zero of that network or region. The
request must be sent by a NetMail message and must include at least the
following:
1) Your name.
2) The name of your system.
3) The city and state where your system is located.
4) The phone number to be used when calling your system.
5) Your hours of operation.
6) The maximum baud rate you can support.
7) BBS Software Version.
8) NetMail Interface Program.
9) A list of EchoMail Conferences that you wish to pick up.
10) Voice number (Internal use only!).
Your coordinator may want additional information. If so, he will
contact you.
Please allow at least three days for a node number request to be
processed. If you send your request to Network Administration, then
he may forward your request to the Network Coordinator who covers your
area (if any), which may take longer.
2.2 If you are going down
If your node will be down for an extended period (more than a day or
two), then you should inform your coordinator as soon as possible. If
you do not do this, then other systems will still try to reach you
while you are down, much to the annoyance of everyone. Do not under
any circumstances put an answering machine or similar device on your
phone line while you are down. If you do, then calling systems will
get the machine repeatedly, racking up large phone bills, which is
very annoying.
If you will be leaving your system unattended for an extended period
of time (such as while you are on vacation), you should notify your
coordinator. Systems do have a tendency to "crash" now and then, so
you will probably want your coordinator to know that it is a temporary
condition if it happens while you are away.
2.3 How to join a network
If you are an independent node and would like to join a network in
your area, you must contact the Network Coordinator. He can be
reached by sending RBBS-NET mail to node zero of the network. He will
inform you of any special mail schedules and/or routing required by
the network. Network Administration will contact you to confirm
that you wish to join the network. Once you have been placed in the
network, you will be informed by the Network Coordinator.
RBBS-PC Network Policy and Procedures Page 6
There are many advantages to being in a network. First and foremost
is that it helps reduce congestion of RBBS-NET during National Mail
Hour. Also, many networks are "outbound" as well as "inbound", which
can substantially reduce your phone bills. In addition, network
members receive regular updates of the Node List, while an independent
node may not.
2.4 How to form a network
If there are several nodes in your area, but no network, then you may
wish to form your own. Again, this has several advantages as outlined
above.
Your first step is to contact the other SysOps in your area. You must
decide which nodes will comprise the network, and which of those nodes
is going to be the Network Coordinator. Your next step is to inform
Network Administration. You must send him a NetMail message with the
following information:
1) The region number(s), or network number(s) if a network is
splitting up, that are affected by the formation of your
network. The Regional Coordinator will inform the
International Coordinator and the coordinators of any
affected networks that a new network is in formation.
2) The name that you wish to call your network. Please try to
select a name that relates to your grouping. For example,
SoCalNet for nodes in the Southern California Area
and MassNet for Massachusetts Area. Remember if you
call yourself DOGNET it doesn't help others know what area
of the country (or even what country) your group is in.
3) A copy of the proposed network's Node List. The Node List
file should be named RBBSNET.nnn where nnn is the
proposed host's current region or network number.
This file should be sent attached to the message of
Application for a Network Number.
SAMPLE FORMAT OF A RBBSNET.911 FILE
Host,911,Inland_Empire_NET,Colton_CA,Rod_Bowman,1-714-381-6013,9600,XA,CM,HST,V
32b,V42b
,1,The_'PC'_Spectrum_(tm)_RBBS-PC,Colton_CA,Rod_Bowman,1-714-381-6013,9600,XA,C
M,HST,V32b,V42b
,2,Chips_Unlimited_RBBS-PC,Rancho_Cucamonga_CA,Phil_Rheinecker,1-714-989-2603,9
600,RE,WK0100-0500,WE,HST
;
Granting of a network number is not automatic. Network Administration
will review your application and inform you of the decision.
RBBS-PC Network Policy and Procedures Page 7
Chapter 3
NETWORK COORDINATOR PROCEDURES
A Network Coordinator has the following responsibilities:
1) To receive incoming mail for nodes in his network, and to
deliver it to its recipients. This mean you have to poll
the Mail Distribution System to receive your mail.
2) To assign node numbers to nodes in his network.
3) To maintain the Node List for his network, and to send a
copy of it to Membership Services whenever it changes.
4) To pass along to his nodes the new Node List, Node List
updates and new issues of RBBS-NET as they are received.
3.1 Routing inbound mail
It is your responsibility as Network Coordinator to receive all
inbound mail for nodes in your network and to forward it to its
recipients. You are left to your own discretion as to how best to
accomplish this.
If a node in your network is routing large volumes of EchoMail, you
can ask him to either limit the amount of EchoMail, or even to stop
routing his EchoMail completely. The design of EchoMail is such that
it is a simple matter to do either of these. Or they can break off out
of your network.
3.2 Assigning node numbers
It is your responsibility to assign node numbers to new nodes in your
network. You may also change the numbers of existing nodes in your
network, though you should check with your member nodes before doing
so. You may assign any numbers you wish, so long as each node has a
unique number within your network.
3.3 Maintaining the Node List
You should attempt to implement name changes, phone number changes, et
cetera in your Node List as soon as possible, and to forward the
revised Node List to Membership Services whenever a change occurs.
You should also on occasion send a message to every node in your
network to ensure that they are still operational. If a node turns
out to be "off the air" with no prior warning given to you, then you
can either mark the node as down, place it in the dog house, or remove
it from the Node List completely, at your own discretion.
RBBS-PC Network Policy and Procedures Page 8
3.4 Passing along Node Lists and RBBS-NET News
As a Network Coordinator you should obtain a new Node List update every
week. The Node List update is posted weekly on Sundays. The list will
be made available to you by Network Administration.
You should pass both of these along to your member nodes as soon as is
practical after you receive them. It is also desirable that you make
them both available for downloading by the general user, but this is
not required.
The Node Lists are the glue that holds us together. Without them, we
cease to be a community, and become just another random collection of
bulletin boards.
RBBS-PC Network Policy and Procedures Page 9
Chapter 4
NETWORK ADMINISTRATION PROCEDURES
Membership Services and RBBS-NET Administration has the following
responsibilities:
1) To assign node numbers to independent nodes in the region.
2) To encourage independent nodes in the region to join
existing networks or to form new networks.
3) To assign network numbers to networks in the region.
4) To compile a Node List of all of the networks and
independents in the region, and to send a copy of it to
the Mail Distribution Node whenever it changes.
5) To ensure the smooth operation of the networks within the
region.
6) To make a new RBBS-NET Node List, create a News Letter and
make them available to the Network Coordinators in the
region as soon as is practical.
4.1 Assigning Node numbers
The responsibility to assign node numbers to new network in the region.
You may also change the numbers of existing networks in the region,
though you should check with the respective nodes before doing so.
The numbers assigned to networks must be within the RBBS-NET Network
Plan in order for future growth of the region to be possible.
You should use network mail to inform a new node of their node number,
as this helps to insure that he is capable of receiving network mail.
If you receive a node number request from a new node that is in an
area covered by an existing network, then you should forward the
request to the Coordinator of that network instead of assigning a
number yourself.
4.2 Encouraging the formation and growth of networks
One of your main duties as a the Network Administration is to promote
the growth of networks in the region.
You should try to avoid having independent nodes in the region which
are within the coverage area of a network. There are, however,
certain cases where a node should not be a member of a network, such
as a commercial system with a large volume of traffic which would clog
the network. The resolution of such special cases is left to your own
discretion.
RBBS-PC Network Policy and Procedures Page 10
If several independent nodes in your region are in a "clump", then you
should encourage them to form a network. Refer to the SysOp procedure
forming a network on forming a network for details of what information
you should get.
Note that this does not mean to encourage the formation of trivial
networks. Obviously, one node does not make a network. The exact
number of nodes required for an effective network must be judged
according to the circumstances of the situation, and should be
according to the plan of the region.
4.3 Assigning network numbers
It is your responsibility to assign network numbers to new networks
forming within your region. The network numbers are assigned by
referring to the RBBS-NET Network Plan.
4.4 Maintaining the Node List
Network Administration has a dual role in maintaining the Node List for
the region.
First, you must maintain the list of independent nodes in your region.
You should attempt to implement name changes, phone number changes,
and so forth in this Node List as soon as possible. You should also
on occasion send a message to every independent node in your region to
ensure that they are still operational. If a node turns out to be
"off the air" with no prior warning given to you, then you can either
mark the node as down, place it in the dog house, or remove it from
the Node List completely, at your own discretion.
Second, you must receive the Node Lists from the Network Coordinators
within your region. You should assemble a master Node List for your
region every week and send it to the International Coordinator no
later than National Mail Hour on Saturday morning. It is suggested that
you do this as late as is practical, so as to accommodate any late
changes.
You will need to maintain a set of Node Lists for each network within
your region, since you cannot count on getting an update from each
Network Coordinator every week.
4.5 Overseeing network operations
It is the responsibility of Network Administration to ensure that the
networks within the region are operating in an acceptable manner.
This does not mean that you are required to operate those networks;
that is the responsibility of the Network Coordinators. It means that
you are responsible for seeing to it that the Network Coordinators
within your region are acting responsibly.
It is the obligation of Network Administration to maintain direct and
reasonably frequent contact with the networks in the region. The
exact method of accomplishing this is left to your discretion.
RBBS-PC Network Policy and Procedures Page 11
4.6 Passing along Node Lists and RBBS-NET News
Network Administration is responsible to obtain the latest RBBS-NET
Node List updates and any RBBS-NET News issues as they are published,
and to make them available to the Network Coordinators within your
region. The Node List is posted weekly on Sunday's by RBBS-NET
Node #8:8/8.
It is your responsibility to distribute these to any Network
Coordinators in your region as soon as is practical after you receive
them. The method of distribution is left to your discretion. You are
not required to distribute them to any independent nodes in your
region, though you may if you wish. It is also desirable that you
make them both available for downloading by the general user, but this
is not required.
RBBS-PC Network Policy and Procedures Page 12
Chapter 5
ECHOMAIL CONFERENCES
EchoMail Conferences are messages that are passed around the
nation. These conferences can range from very technical
ordinated to very religious. Some may even have offensive
language in them. So, it is very important that you only
choose the ones that would be of interest to you and/or your
users. You can always add and/or delete the conferences that
you choose.
For a current list of the available EchoMail Conferences, ask
your Netmail Manager for the current list. It will also be
available for download and/or file requestable from
Membership Services at #8:8/10 as ECHOLIST.ZIP
If you are receiving EchoMail Conferences from RBBS-NET, it is
mandatory that you NOT forward RBBS-NET or any another Network
EchoMail Conferences to NON RBBS-NET Systems. Also, do not
accept feeds of the same EchoMail Conference from more than
one source. If you do, it will create duplicate messages in
EVERYONES Network. Violation of this will not be tolerated!
The following are REQUIRED RBBS-NET EchoMail Conferences:
RBBS-SYSOP This conference will be the RBBS-NET SysOp's
Conference and will be available to all RBBS-NET
Nodes. This is also a PUBLIC Conference ... so
it can be made available to the callers of your
system on an RBBS-NET Node. Moderators: Rod
Bowman and Don Smith
RBBS-NET This is a PRIVATE Conference which is only
available to the RBBS-NET Net Managers. This
conference will be used for Net Manager
Information between them and RBBS-NET Network
Administration. This should be listed in
your AREAS.NET File as "sysop-only"! (This Echo
Mail Conference is also available to the Hub
Manager.) Moderators: Rod Bowman and Don Smith
RBBS_DEV This is a PRIVATE Conference which is only
available to nodes of RBBS-NET. This conference
will be used for the development of The RBBS-PC
Network. This should be listed in your
AREAS.NET File as "sysop-only" also! This Echo
Mail Conference is ONLY for RBBS-NET Development
Information and should not be used for anything
else. Moderators: Rod Bowman and Don Smith
RBBSBITS This is a PUBLIC Conference which is only
available to nodes of RBBS-NET. This conference
will be used for chatter about the RBBS-NET News
Letter. Moderators: Rod Bowman and Don Smith
RBBS-PC Network Policy and Procedures Page 13
The following are OPTIONAL RBBS-NET EchoMail Conferences:
DOORWARE This is a PUBLIC Conference which is available
to all the RBBS-NET Members. This Conference
is also Gated into other networks. It is chaired
by Rod Bowman who is the one of the authors of
for the DOORWARE (tm) Programs and he is also
the who created the Standard Door Interface for
the use of other Door and BBS Programmers.
Moderator: Rod Bowman @ 8:8/8
RBBS_4SALE This conference will be the RBBS-NET For Sale
Conference and will be available to all RBBS-NET
Nodes. This is also a PUBLIC Conference ... so
it can be made available to the callers of your
system on an RBBS-NET Node. Moderator: Michael
Henderson @ 8:930/201
RBBS_BETA This is a PRIVATE Conference which is only
available to the Beta Testers of the RBBS-PC
Software Program. Access to this Conference can
is only available to official Beta Test Sites in
RBBS-Net. Moderators: Rod Bowman @ 8:8/8 and
Ken Goosens @ 8:935/101
RBBS_MSGTOSS This conference will focus on the MSGTOSS
software utility and will be available to all
RBBS-NET Nodes. This is also a PUBLIC
Conference ... so it can be made available to
other SysOps on your RBBS-Net Node system.
Moderator: Craig Gagner @ 8:928/102
RBBS_POL This conference will be for discussions regarding
POLICY in RBBS-NET. This conference is available
to all RBBS-NET Nodes. This is also a PUBLIC Echo
so it can be made available to all callers of
your system on an RBBS-NET Node. Moderators:
Rod Bowman @ 8:8/8 and Don Smith @ 8:8/10
RBBS_SRC This is a PRIVATE Conference which is only
available to nodes of RBBS-NET. This conference
will be used for the discussions of RBBS-PC
Source Code Changes. This should be listed in
your AREAS.NET File as "SysOp-ONLY" also!
RBBS_SD This is a PRIVATE Conference which is only
available to nodes of RBBS-NET. This conference
will be used for the discussions of the Software
Distribution Services for RBBS-NET. This should
be listed in your AREAS.NET File as "SysOp-ONLY"
also! Moderator: [OPEN]
RBBSMAIL_PACK This is a PUBLIC Conference which is available
to all the RBBS-NET Members. This Conference
is also Gated into other networks. It is chaired
by Rod Bowman, one of the authors of the program
called: RBBSPACK This conference is used as a
is used as a support Echo for this program as
well as the support Echo for the program called:
RBBSMail. Moderators: Rod Bowman @ 8:8/8 and
Jan Terpstra @ 2:510/10
RBBS-PC Network Policy and Procedures Page 14
SMLWARE This is a PUBLIC Conference which is available
to all the RBBS-NET Members. It is chaired by
Darwin Collins who is the author of all of
the SMLWare Programs and by Mike Davis. This
Conference will be used to help support those
programs. Moderator: Mike Davis @ 8:930/1
RBBS-PC Network Policy and Procedures Page 15
Chapter 6
RBBS-PC NETWORK CONTACTS
Rod Bowman Don Smith
Network Administration Membership Services
Colton, California Tiffin, Ohio
(D) 714-381-6013 (D) 419-448-1452
RBBS-NET Node #8:8/8 RBBS-NET Node #8:8/10
FidoNet Node #1:10/8 FidoNet Node #1:234/23
Jan Terpstra
Europe Gateway
Beemster, Holland
(D) 31-2998-3603
RBBS-NET Node #8:8/2
FidoNet Node #2:512/10
RBBS-PC Network Policy and Procedures Page 16
Chapter 7
ACKNOWLEDGMENTS
IFNA The International FidoNet Association for creating
standards for Packet Mail to be transmitted across the
nation.
RBBS-PC Remote Bulletin Board Service Program written by Tom
Mack, Jon Martin, Ken Goosens and Doug Azzarito.
NetMail DOORWARE Program written by Bob Westcott and Rod Bowman
which makes RBBS-NET all possible for RBBS-PC Systems.
BinkleyTerm The Front End Program for the Interface to a FidoNet
Compatible Network written by Bob Hartman.
RBBS-NET The RBBS-PC Network created by Rod Bowman and the help
of many others.
RBBSPACK The Zone Aware EchoMail Packer and Router Program which
was written by Jim Oswell and Rod Bowman.
RBBSMail A program written by Jan Terpstra that allows a SysOp
to pull EchoMail Conferences into RBBS-PC.
Bob Westcott For all of his work on the DOORWARE Programs.
Kim Wells For all of his work with the interface between RBBS-PC
and SeaDog.
George Peace For making mods to the QM Program which really help out
with the processing of mail and for his help and support
he has given RBBS-Net.
Bowman Family I would like to thank them for allowing me the time to
work on my (expensive) hobby.
RBBS-PC Network Policy and Procedures Page 17
